Digital signatures show where programs come from and verify that they haven't been altered. You should digitally sign your customized browser package and any custom programs to ensure that users don't receive warnings when installing their custom browsers. Users may be prevented from installing ActiveX controls and Java packages that aren't signed. You must specify information about your digital certificate when using the IEAK wizard.
When creating custom browser packages, you should sign the custom cabinet (.cab) files created by the IEAK before you post them to the Internet or an intranet. Signing the .cab files and custom programs requires two steps: obtaining a digital certificate and signing the code.
After you obtain a digital certificate, you must accept this certificate on your computer. Then in the IEAK wizard, you will be prompted to select the publisher certificates you will use to sign the files in your package.
After you create your browser package, you must sign the following files:
Notes
Digital certificates are a part of Authenticode technology, which identifies where programs come from and verifies that programs haven't changed. Certificates are obtained from one of two sources. A certificate authority (CA) such as VeriSign or GTE can provide certificates, or a privately controlled certificate server can issue certificates.
For the latest information, see the Microsoft Web site at http://www.microsoft.com/, and search for the words "authenticode," "digital certificate," and "certificate authority."
Companies that do not want to take on the tasks associated with being a CA may become local registration agencies (LRAs). The LRA views enrollment requests, verifies evidence, and passes on the approved request to the signing CA. The CA and the LRA may vary on the terms of their arrangement, which is structured in a contract.
The following example describes a CA and LRA relationship. VeriSign may be a root CA providing full CA services. A university may want to provide certificates for all of the students in its master's program. The university may authenticate the identity of its students and track the necessary paperwork, but may not want to handle liability issues. Thus, the university might want to pass on the liability issues to a root CA, and establish itself as an LRA.
Tools for signing code, such as the Code Signing Wizard (Signcode.exe), are available in the IEAK Resource Kit. You can find them in the \Program Files\IEAK\Reskit\Tools folder.
You will also need to know the public and private keys, which are a matched set of keys created by the software publisher and used for encryption and decryption. The keys are generated at the time the certificate is requested from a CA. They are generated on your computer, and your private key is never sent to the CA or any other party.
Authenticode is a technology based upon specifications that have been used successfully in the industry for some time, including PKCS #7 (a Cryptographic Message Syntax Standard), PKCS #10 (certificate request formats), X.509 (certificate specification), and SHA and MD5 hash algorithms.
CAs publish policies and act to grant code-signing authority (certificates) based on criteria established in various specifications. Other CA duties include managing certificates (enrollment, renewal, and revocation), storing root keys, verifying evidence submitted by applicants, providing tools for enrollment, and accepting the liability associated with handling these items. CAs are an important element of this program, as they ensure that all software publishers are working according to the same set of rules.
The expiration of certificates provides an added measure of security. (For example, if a university certifies all of its students with digital IDs, it could set each ID to expire when the student leaves the university.) Code that is signed with an expired certificate is invalid. When the certificate expires, the software publisher will need to resign its code and post new versions of this code. In the future, when an Internet time stamp is available, software publishers will be able to sign code with a time stamp to prove that the certificate was valid at the time the code was signed; then the signed code will remain valid even after the certificate expires.
Internet Explorer provides more than one security level by dividing the Internet into zones. Security zones help users avoid potentially harmful content on the Internet.
Users can tell which zone the current Web page is in by looking at the right side of the Internet Explorer status bar. Whenever you attempt to open or download content from the Web, Internet Explorer checks the security settings for that Web site's zone.
Content is assigned to zones in several ways. While actions for each security level are defined, users can create custom settings for each level.
If you're a corporate administrator, you can preconfigure security zones, preset ratings, and customize Certificate Authorities. You can also control whether users can modify their security settings through system policies and restrictions. For information about specific settings, see Internet Explorer Security Options.
You can ensure that end users receive warnings when they try to view potentially unsafe content. You can also prevent users from downloading unsigned ActiveX controls and Java packages.
The code-signing process is simple and quick. It isn't necessary to know the technical details of how code-signing works to sign your code.
After developing and testing code, a software publisher signs the code. The code is run through a one-way hash function that produces a fixed-length "digest." The digest is then encrypted with the software publisher's private key and combined into a signature block with the name of the hash algorithm and certificate (which holds the name of the publisher, the public key, the name of the CA's certificate, and so on). This signature block is then inserted back into the portable-executable (PE) file format under a reserved section, and the code is distributed over the Internet. If you are signing a .cab cabinet file, the signature block is also stored in the cabinet file.
When the user downloads the code, the downloading application calls the WinVerifyTrust API. The system extracts the signature, determines the CA who authenticated the certificate, and obtains the software publisher's public key distributed by that CA. The system then uses the public key to decrypt the digest. It runs the specified hash on the code again, creating a new digest. If the code has not been modified since it was signed, the new digest should match the old one. If the two digests don't match, either the code was modified, or the public and private keys aren't a matched pair. In either case, the code becomes suspect and the user is warned.